Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.changeset/unified-domain-model.md:
- Line 14: The changeset currently documents makeENSv1DomainId as taking
(AccountId, Node) but semantically ENSv1DomainId is
`${ENSv1RegistryId}/${node}`; update the documentation to state the first
parameter is ENSv1RegistryId (i.e., change the signature description to
`(ENSv1RegistryId, Node)`) while noting the implementation still accepts
AccountId-convertible values if you want, and keep the note that makeRegistryId
remains as a union-returning helper for callers that cannot narrow to specific
registry constructors like makeENSv1RegistryId, makeENSv2RegistryId, and
makeENSv1VirtualRegistryId.

In `@AGENTS.md`:
- Line 85: Update the line that instructs running `pnpm generate:gqlschema` to
specify when it's required: state that developers must run `pnpm
generate:gqlschema` whenever GraphQL SDL/schema files, GraphQL-related
TypeScript types, resolver signatures, queries/mutations/subscriptions, or any
files that define the GraphQL schema are changed (i.e., adding/removing fields,
types, directives, or changing type shapes), so that generated schema and types
stay in sync with source; reference the existing command `pnpm
generate:gqlschema` and replace "was affected" with this explicit list of change
types in AGENTS.md.
- Line 84: The sentence "If OpenAPI Specs were affected, run `pnpm
generate:openapi`" is ambiguous and inconsistent with existing CI wording;
change it to use lowercase "specs" and be more specific about when to run the
command (e.g., when you modified ENSApi routes or request/response types).
Update the line that currently reads "If OpenAPI Specs were affected, run `pnpm
generate:openapi`" to something like "If you modified ENSApi routes or
request/response types, run `pnpm generate:openapi`" and use "specs" rather than
"Specs" to match the CI messages.

In `@apps/ensapi/src/omnigraph-api/schema/domain.ts`:
- Around line 70-74: The type guards isENSv1Domain and isENSv2Domain declare
(domain: unknown) but directly access (domain as DomainInterface).type which can
throw on null/undefined or mis-handle primitives; update each guard to first
confirm domain is a non-null object and has a "type" property (e.g., typeof
domain === "object" && domain !== null && "type" in domain && typeof (domain as
any).type === "string") before comparing to "ENSv1Domain"/"ENSv2Domain", or
alternatively change the parameter type from unknown to DomainInterface if
callers never pass unknown.

In `@apps/ensindexer/src/lib/ensv2/domain-db-helpers.ts`:
- Around line 19-22: The inline comment above the update call is stale—update or
remove it so it no longer references `v1Domain`; change the comment to reflect
that you're updating the unified `ensIndexerSchema.domain` table (or delete the
comment). Locate the update invocation using
`context.ensDb.update(ensIndexerSchema.domain, { id }).set({ ownerId:
interpretAddress(owner) })` and replace the comment accordingly.

In `@apps/ensindexer/src/lib/managed-names.test.ts`:
- Around line 68-74: The test for getManagedName currently checks that the
BaseRegistrar instance (registrar) returns { name: "eth", node: ETH_NODE,
registry: ensv1Registry } but omits a parallel assertion for the
LegacyEthRegistrarController; add an assertion that calling
getManagedName(controller) (or the test variable representing
LegacyEthRegistrarController) returns an object whose registry field is the same
ensv1Registry (and optionally name/node equal to the expected values) so the
controller canonicalizes to the same registry as the registrar.

In `@SPEC-domain-model.md`:
- Line 437: Fix the typo in the documentation snippet for the RegistryIdInput
AccountId resolver: change the filter fragment `'ENSv1Registry',
'ENSv2Registry)` to include the missing closing quote so it reads
`'ENSv1Registry', 'ENSv2Registry'`; reference the same logical resolver name
"RegistryIdInput AccountId resolver" (the actual implementation uses
["ENSv1Registry","ENSv2Registry"]) to verify consistency and update the markdown
accordingly.
- Around line 36-42: Add blank lines before and after the fenced code blocks and
include a language hint for the dependency graph fence to satisfy markdownlint
(MD031/MD040). Specifically, in the snippet containing getManagedName(registry)
and makeENSv1VirtualRegistryId(registry, parentNode) ensure there is an empty
line above the opening ```ts and below the closing ```; apply the same
blank-line padding to the other fenced blocks around the dependency graph and
annotate that graph fence with a language tag such as ```text.

---

Outside diff comments:
In `@apps/ensindexer/src/plugins/ensv2/handlers/ensv1/BaseRegistrar.ts`:
- Around line 39-51: The file-level doc comment for BaseRegistrar is stale: it
repeatedly refers to v1Domain and materializing v1Domain.owner, but the handler
now writes into the unified ensIndexerSchema.domain; update the comment to use
current terminology (replace v1Domain references with the unified
ensIndexerSchema.domain/domain record and describe conditional materialization
of the domain owner there) and mention BaseRegistrar (and BaseRegistrar-derived
registrars/controllers) only in terms of how they can create preminted names
that result in entries in ensIndexerSchema.domain rather than a separate
v1Domain table.

In `@packages/ensdb-sdk/src/ensindexer-abstract/ensv2.schema.ts`:
- Around line 191-247: Polymorphic invariants (registry.node, domain.tokenId,
domain.node) are only documented and not enforced; add typed insert helpers that
validate and set discriminators to prevent invalid writes. Implement functions
like insertENSv1Domain and insertENSv2Domain (and insertENSv1VirtualRegistry if
needed) which accept strongly-typed payloads, set the domain.type/registry.type
discriminator, require and validate the non-null fields (for ENSv1Domain require
node; for ENSv2Domain require tokenId; for ENSv1VirtualRegistry require node on
registry), and call the underlying table insert; replace ad-hoc writes to domain
and registry with these helpers so all writes enforce the invariants at the API
layer. Ensure the helpers are named and exported clearly (insertENSv1Domain,
insertENSv2Domain, insertENSv1VirtualRegistry) and add minimal runtime checks
that throw descriptive errors when invariants are violated.

In `@packages/enssdk/src/lib/types/ensv2.ts`:
- Around line 13-40: The ENSv1VirtualRegistryId and ENSv1DomainId are currently
byte-identical strings and should be made runtime-distinguishable: change the
canonical serialized shape of ENSv1VirtualRegistryId to include a prefix (e.g.
"vreg:") so it becomes `vreg:${ENSv1RegistryId}/${node}`, update any
constructors/parsers/serializers/validators (places that build or parse
ENSv1VirtualRegistryId) to add/strip that prefix, update comments and tests
referring to ENSv1VirtualRegistryId, and ensure GraphQL inputs, cache key code
and cross-table join logic use the new prefixed form (or accept both forms
during a compatibility transition if needed); keep the TypeScript brand types
ENSv1VirtualRegistryId and ENSv1DomainId but document the new runtime format.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@AGENTS.md`:
- Around line 87-90: The file contains a duplicate "## Testing" heading; merge
the two by moving the two bullets ("Prefer the `await expect(...).resolves.*`
format over await-then-expect." and "Prefer `await
expect(...).resolves.toMatchObject({})` over expecting individual properties, if
it is more concise.") into the existing "## Testing" section (the original "##
Testing" header) and delete the duplicate "## Testing" section at the bottom so
there is a single consolidated testing section.

In `@apps/ensapi/src/omnigraph-api/lib/find-domains/canonical-registries-cte.ts`:
- Around line 42-44: The reduce over roots to build rootsUnion can throw when
roots is empty; update getRootRegistryIds to guard and fail fast by checking
roots.length > 0 and throwing a clear error (e.g. "no root registries
configured") before the reduce, or provide a safe initial value to the reduce so
it never calls reduce on an empty array; locate the roots variable and the
rootsUnion construction in canonical-registries-cte.ts (the rootsUnion
definition) and implement one of these two fixes so an empty/misconfigured
namespace produces an explicit, descriptive failure instead of a TypeError.
- Around line 56-68: Update the JSDoc to reflect that the recursive CTE walks
Domain.subregistryId (i.e., "each Registry is reached via any Domain's
subregistryId within a canonical Registry, covering both ENSv1 virtual
registries and ENSv2 subregistries") instead of mentioning
registryCanonicalDomain, and modify the final CTE projection in
canonical_registries (the SELECT registry_id FROM canonical_registries) to
SELECT DISTINCT registry_id FROM canonical_registries to prevent duplicate
registry IDs from duplicating rows downstream (affects filterByCanonical's
innerJoin and pagination/counts); the change touches the canonical_registries
CTE (rootsUnion, CANONICAL_REGISTRIES_MAX_DEPTH) and relates to
filterByCanonical behavior.

In `@apps/ensapi/src/omnigraph-api/schema/query.integration.test.ts`:
- Around line 148-164: The test "filters by canonical" in
query.integration.test.ts is too weak—add a negative assertion to ensure
non-canonical domains are excluded: update the DEVNET_NAMES test fixtures to
include a known non-canonical domain (one that should not be canonical under the
logic in canonical-registries-cte.ts), then in the "filters by canonical" test
(the QueryDomains invocation and flattenConnection usage) assert that this
non-canonical fixture is not present in the returned domains (e.g., find by
name/id and expect it toBeUndefined or not found) so that leakage of
non-canonical v2 entries is detected.

In `@apps/ensapi/src/omnigraph-api/schema/registry.ts`:
- Around line 48-55: Change the three type-guard signatures isENSv1Registry,
isENSv1VirtualRegistry, and isENSv2Registry from (registry: unknown) to
(registry: RegistryInterface) so they no longer rely on unsafe casts and mirror
the domain.ts guards; update the callers that pass values into these guards (the
places using them as isTypeOf) to cast their argument to RegistryInterface
(e.g., value as RegistryInterface) before calling the guard, keeping the guard
implementations unchanged except for the parameter type.

In `@packages/ensnode-sdk/src/shared/root-registry.ts`:
- Around line 128-139: getRootRegistryIds currently omits ThreeDNS, so
ThreeDNSToken contract addresses must be included as top-level v1 registries;
update getRootRegistryIds to add maybeGetDatasourceContract(namespace,
DatasourceNames.ThreeDNSBase, "ThreeDNSToken") and
maybeGetDatasourceContract(namespace, DatasourceNames.ThreeDNSOptimism,
"ThreeDNSToken") into the v1Registries array (same filter/map to AccountId and
makeENSv1RegistryId) so ThreeDNS domain subtrees are reachable by
canonical-registries-cte/getDomainIdByInterpretedName; alternatively, if you
prefer the other approach, narrow the schema comment in ensv2.schema.ts to
remove ThreeDNS from the list of concrete ENSv1Registry rows.

---

Duplicate comments:
In `@apps/ensindexer/src/plugins/ensv2/handlers/ensv1/ENSv1Registry.ts`:
- Around line 103-113: The update to set domain.subregistryId using
context.ensDb.update(ensIndexerSchema.domain, { id: parentDomainId }).set({
subregistryId: parentRegistryId }) can silently affect 0 rows if the parent
domain row doesn't exist; change the logic to guarantee the parent exists or
fail loudly: before the update either perform an insert-or-no-op (e.g.
ensureDomain-style upsert into ensIndexerSchema.domain for parentDomainId) or
execute the update and check the result row count and throw an error if zero,
and only then insert/update ensIndexerSchema.registryCanonicalDomain; this will
make functions like ENSv1Registry (parentDomainId, parentRegistryId) fail fast
instead of leaving a canonical link without a subregistryId.